feat(amd): first-class R9700 (gfx1201/RDNA4) support for Qwen3.6-27B#435
Open
DeanoC wants to merge 2 commits into
Open
feat(amd): first-class R9700 (gfx1201/RDNA4) support for Qwen3.6-27B#435DeanoC wants to merge 2 commits into
DeanoC wants to merge 2 commits into
Conversation
The HIP build pipeline compiled RDNA4 as gfx1200 (Navi 44, RX 9060) and mislabeled it 'RX 9070'. The Radeon AI PRO R9700 is gfx1201 (Navi 48), which is NOT code-object compatible with gfx1200 — so the published :rocm image and the documented build shipped no native R9700 kernels. - Add gfx1201 to the default fat-binary HIP arch list (docker-bake.hcl, Dockerfile.rocm, CI main/release matrix) and correct the RDNA4 labels. - Build the rocWMMA flashprefill numerics test (test_flashprefill_kernels) under HIP too, not just CUDA, so the Phase 2 path can be validated on AMD. - Document the R9700: gfx1201 build, --ddtree-budget=22, the multi-GPU / Fedora-PIE build notes, and benchmark numbers. Validated on a real R9700 (gfx1201, ROCm 7.1.1): - test_server_unit: 1984 assertions, 0 failures - test_flashprefill_kernels (rocWMMA): PASS, max diff 5e-4 - Qwen3.6-27B Q4_K_M + DFlash, budget=22: 54.65 tok/s mean decode (AL 7.14) - coherent 16K-context generation Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The json FetchContent_Declare gained DOWNLOAD_EXTRACT_TIMESTAMP TRUE in Luce-Org#433 to silence the CMP0135 dev warning. That keyword (and CMP0135) only exist on CMake >= 3.24; on the 3.22 base used by the cuda12/rocm Docker builds the unknown token is parsed as extra URL list entries, failing configure with 'At least one entry of URL is a path (invalid in a list)'. This broke the Docker prebuilds on main, independent of the R9700 work. Apply the option only on CMake >= 3.24 (where it still silences the warning); older CMake parses the declare correctly again. Reproduced and verified on CMake 3.22.6 and 4.3. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Makes the AMD Radeon AI PRO R9700 (
gfx1201, RDNA4 / Navi 48) a first-class AMD target for the DFlash Qwen3.6-27B stack, and fixes a CMake-version build break that affects thecuda12/rocmDocker images.1. R9700 /
gfx1201supportThe HIP build pipeline compiled RDNA4 as
gfx1200(Navi 44, RX 9060-class) and mislabeled it "RX 9070". The R9700 isgfx1201, which is not code-object compatible withgfx1200— so the published:rocmimage and the documented build produced no native R9700 kernels (ggml-hip fails to load / falls back badly on the R9700).gfx1201to the default fat-binary HIP arch list indocker-bake.hcl,Dockerfile.rocm, and the CI main/release matrix (.github/workflows/docker.yml). PR builds staygfx1151-only for fast CI. Corrected the RDNA4 labels (gfx1200= RX 9060,gfx1201= RX 9070 / R9700).test_flashprefill_kernels) under HIP too — it was CUDA-only, so there was previously no way to validate the rocWMMA path on AMD. The CUDA-spelled test compiles via the existinghip_compat/shim.server/README.mdAMD HIP section (gfx1201build,--ddtree-budget=22, multi-GPU / Fedora-PIE build notes).No kernel changes: ROCm 7.1's rocWMMA handles the gfx12 WMMA operand-format change internally.
2. Build fix:
jsonFetchContent on CMake < 3.24#433 added
DOWNLOAD_EXTRACT_TIMESTAMP TRUEto thejsonFetchContent_Declare. That keyword (and policyCMP0135) only exist on CMake ≥ 3.24, but thecuda12/rocmDocker base images ship CMake 3.22, where the unknown token is parsed as extraURLlist entries and configure fails withAt least one entry of URL is a path (invalid in a list). The option is now applied only on CMake ≥ 3.24 (where it still silences the dev warning); older CMake parses the declare correctly again. Reproduced and verified on CMake 3.22.6 and 4.3.Validation — real R9700 (
gfx1201, ROCm 7.1.1)Native
gfx1201build (Phase 1 + Phase 2 rocWMMA); the builtlibggml-hip.socontains nativehipv4-amdgcn-amd-amdhsa--gfx1201code objects.test_server_unittest_flashprefill_kernels(rocWMMA)flash_prefill_forward_bf16@ S=8192 = 10.7 ms/iter--ddtree-budget=22bench_he.py --n-gen 256, AL 7.14, range 36.9–93.0 tok/s)Notes
/usrand links PIE by default; the local build used-DCMAKE_HIP_COMPILER_ROCM_ROOT=/usr -DROCM_PATH=/usr -DCMAKE_EXE_LINKER_FLAGS=-no-pie(documented inserver/README.md). The Ubuntu-basedDockerfile.rocmis unaffected.